1. Field of the Invention
The invention relates to methods for distributing data packets of communication connections to nodes in network element clusters and to network element clusters, where such methods are applied. Especially, the invention is related to such a method as specified in the preamble of the independent method claim.
2. Description of Related Art
The public networks are presently being used more and more for sensitive and mission critical communications and the internal networks of various organisations and enterprises are nowadays connected to the public networks, Internet being one of them. Since the basic mechanisms of the public networks were originally not designed with secrecy and confidentiality in mind, public networks are untrusted networks. To protect an internal network, a special network element is usually used to connect the internal network to a public network. Typically such network element monitors the connections traversing the network element and possibly modifies the data packets of the connections according to predetermined rules. Methods such as network address translation (NAT) and protocol conversions are methods requiring that the data packets are modified in such network elements. Also other modifications on the data packets traversing the network element may be performed. This kind of network element is often called a security gateway or a firewall.
The above described security gateway may consist of several similar security gateway (=nodes), i.e. it may be a security gateway cluster. The nodes of a cluster serve as backup nodes to each other and the load handled by the cluster may be balanced between the nodes. The clustered structure increases availability and distributes the load, therefore reducing the probability of a downtime to nearly zero and increasing the throughput of the security gateway. FIG. 1 illustrates a configuration where there are 3 nodes A1, A2, and A3 in security gateway cluster CA and 5 nodes B1, B2, B3, B4, and B5 in security gateway cluster CB. Nodes A1, A2, and A3 connect the internal network A to the public network 10, and nodes B1, B2, B3, B4, and B5 connect the internal network B to the public network 10. In the structure of FIG. 1, each internal network is connected to the public network via only one Internet service provider (ISP). It is alternatively possible that each internal network is connected to the public network via a number of ISPs, however this issue is not addressed any further here.
Within a cluster all nodes may have an individual IP addresses or they may have a common IP address. Alternatively, nodes may have both a common IP address and an individual IP address. Typically nodes share a common IP address using which the cluster is addressed. In that case all nodes see all data packets arriving at the cluster and there has to be an arrangement for distinguishing which data packets belong to which node. That is, each node should process only those packets that are assigned to it and ignore other data packets. Therefore the data packets arriving at the cluster need to be distributed to different nodes of the cluster. Typically the nodes filter all arriving data packets and decide for example on the basis of the plaintext header field(s) of the packet whether that particular node needs to process that particular packet. Individual IP addresses may be used for e.g. node dedicated control traffic.
It is advantageous that the same node that processes outbound data packets (i.e. packets received from the internal network) processes also the inbound data packets (i.e. packets received from the public network) related to the same connection. In other words, it is advantageous that one node processes all data packets of one connection. In fact, if all packets of a connection are not handled by the same node, the connection typically fails, unless processing of the connection is properly transferred from one node to another. Transferring the connections is however beyond the scope of this application and will not be addressed any further here.
A simple way to distribute data packets to nodes is to use information found in the plaintext header fields of the data packets for this purpose. It is common to use source and destination addresses and ports of data packets. A data packet is here referred to as (source address, source port, destination address, destination port). Consider for example a client C1 with address 10.1.1.10 in the internal network A of FIG. 1 connecting to a server S with address 1.1.1.1 in the public network 10. An outbound data packet (10.1.1.10, X, 1.1.1.1, Y) from the client C arrives at the cluster CA. On the basis of the addresses 10.1.1.10 and 1.1.1.1 the data packet (10.1.1.10, X, 1.1.1.1, Y) is processed by node A1. It may have been decided that all data packets between these endpoints are processed by the node A1 or the decision may be based on some function calculated on the addresses 10.1.1.10 and 1.1.1.1 and ports X and Y. If the node A1 does not alter the addresses of the data packet, it is straightforward to map also the inbound reply packets (1.1.1.1, Y, 10.1.1.10, X) of the same connection to the node A1. It is clear that in this case it is easy to assign a connection between another client C2 with address 10.1.1.11 in the internal network A and the same server S or a connection between some port Z of the client C1 and the port Y of the server S to some other node than node A1. This is advantageous especially, if there are several connections from several sources to the same server, which is usually the case with e.g. popular web servers.
The above situation is different, if the node A1 does alter the addresses of the data packet. Consider for example NAT. One well known way to employ NAT is to hide all addresses of an internal network behind one (or more) address(es). In this case, lets assume that there is a NAT rule according to which the addresses of the internal network A are replaced by address 192.98.99.65 in the nodes A1, A2 and A3, and the source port is replaced by some suitable value for identifying the original source. This means that the outbound data packet (10.1.1.10, X, 1.1.1.1, Y) is modified to (192.98.99.65,R, 1.1.1.1, Y) resulting in inbound data packets (1.1.1.1, Y, 192.98.99.65, R). Now outbound data packets (10.1.1.10, X, 1.1.1.1, Y) and inbound data packets (1.1.1.1, Y, 192.98.99.65, R) have in common only the address 1.1.1.1 and the port Y of the server. In order to map inbound and outbound data packets of the same connection to the same node, all connections terminating at port Y at the server S need to be processed by the same node. If there are several such connections this is clearly not desirable, since it mitigates the possibilities to balance the load between the nodes.
It is also possible that inbound and outbound data packets of the same connection do not have anything in common in their plaintext header fields. For example, secure tunnels may be like this. Nevertheless, also in that case the data packets of one connection should be processed by the same node.
One widely used structure for secure communications is the virtual private network (VPN). A virtual private network is established on top of an untrusted network such as the Internet by constructing encrypted data transmission channels. A virtual private network is typically used to connect distant offices of an organization to each other over a public network. All traffic from the internal network of a first office directed to a second office is encrypted by a network element at the first office, sent in encrypted form over the public network to the second office, where a network element decrypts the transmitted data and forwards the decrypted data to the internal network of the second office. The network element performing the encryption is typically a security gateway. The VPN is typically transparent to the processes that are communicating between each other.
Virtual private networks are typically constructed using the IPSec protocol suite. The IPSec protocol suite is described in the standard RFC 2401 “Security Architecture for the Internet Protocol”. IPSec offers access control, connectionless integrity, data origin authentication, protection against replays, confidentiality (encryption), and limited traffic flow confidentiality. The IPSec protocol suite provides an infrastructure for the data transmission and encryption processes, but does not define any specific encryption method. Many different kinds of encryption methods can be used for IPSec connections. Virtual private networks typically use so called tunnel mode, in which an entire data packet is encrypted, and the result is transmitted as a payload in another data packet. IPSec traffic is unidirectional. An IPSec tunnel, for example, consists of at least one pair of Security Associations.
A Security Association (SA) is a simplex logical connection that affords security services to the traffic carried by it. Security Associations are described in RFC 2401. In IPSec security services are afforded to a SA by the use of authentication header (AH, described in RFC 2402), or encyption of security payload (ESP, described in RFC 2406, but not both. If both AH and ESP protection is applied to a traffic stream using IPSec, then two (or more) SAs are created to afford protection to the traffic stream. To secure typical, bi-directional communication between two security gateways, two Security Associations (one in each direction) are required. Between security gateways the Security Associations are tunnel mode associations. This means that a secured data packet (which is secured with AH or ESP) is encapsulated within an outer data packet having plaintext headers. The plaintext header indicate, for example, the source and destination security gateways.
The security gateway providing VPN functionality may be clustered. The number of nodes may be different at different endpoints of the VPN. Clustering may also be applied to one endpoint of a VPN only.
Usually each node in a cluster is responsible for handling certain connections. It is possible, for example, that an IPSec tunnel is established between a specific node of a first cluster and a specific node of a second cluster, for example between A2 and B4 in FIG. 1. Alternatively, in the other endpoint there may be only one security gateway instead of a cluster. If a specific node of a cluster is an endpoint of an IPSec tunnel, the other endpoint of the IPSec tunnel knows the IP address of the node in the cluster. This may be a problem, for example, when that specific node is overloaded or crashes. It is not possible to change an IPSec tunnel from one endpoint to another; a new tunnel has to be set up instead.
Typically an IP header of a packet received from the internal network is in plaintext and a node which processes an outbound data packet can be determined using a plaintext data packet header. If the IP headers of both the inbound and outbound data packets were plaintext, it would be easy to direct the inbound packets to the same node that processed the outbound packets as was explained in the above description. The problem here is that the inbound IP packet is typically an IP packet, in which an encrypted IP packet is encapsulated. Information about the IP header of the encapsulated, encrypted packet is needed in selecting the correct node. This IP header is, however, typically encrypted. The plaintext IP header of the inbound data packet indicates the address of the cluster and the other endpoint of the VPN, instead of the addresses of the actual source and destination endpoints. One solution is that each node decrypts each inbound data packet, and decides only thereafter if the packet belongs to it or not. Decrypting each inbound data packet header in each node is a waste of resources, and this solution is not feasible in practice.
Also other network elements may be clustered in the similar way to the security gateways. One example of such network elements is a web server. The load of a busy server may be balanced between a plurality of nodes of a server cluster. Typically the nodes have a common IP address, and the server cluster seems to be one single server to the clients.
In the case of web servers there is no problem in distributing the data packets of the same connection since a server is an end point of the connections. Nevertheless, it is advantageous that all connections relating to the same communication session between one client and the server cluster are processed by the same server node. The first connection of a communication session may be directed to any one of the nodes, but it is desirable, that all subsequent connections relating to the same communication session are directed to the same node, which processed the first connection. For the sake of consistency within the text, here the term inbound data packet refers to a data packet received at a server from the network the server cluster is connected to and the term outbound data packet refers to a data packet sent from the server cluster to the network the server cluster is connected to.
SSL (Secure Sockets Layer) protocol is a well known security protocol, which provides communications privacy over public networks. The protocol allows clients and servers to communicate in away that is designed to prevent eavesdropping, tampering, or message forgery. When an SSL client and server first start to communicate, they select cryptographic algorithms, optionally authenticate each other, and use public-key encryption techniques to generate shared secrets. These processes are performed in SSL handshake protocol, which includes exchanging a plurality of messages between the client and the server and establishing a Session ID. A Session ID is an arbitrary byte sequence chosen by the server to identify an active or resumable communication session. After the handshake is complete, the client and the server may start to transfer actual data. When the client and the server decide to open another connection relating to an already opened communication session, resume a previous communication session or to duplicate an existing communication session, i.e. not to negotiate new security parameters, the connection can be accepted and old security parameters can be taken into use by means of the Session ID of the communication session.
In a server cluster, all connections relating to the same Session ID need to be processed by the same server node. The first connection may be arbitrarily directed to one of the nodes, but the subsequent connections of the same communication session need to be directed to the same node. One way to do this is to inspect inbound and outbound data packets in order to find out the Session ID that is established during the handshake phase. Then knowledge of the Session ID and of the corresponding node processing the connection is stored. On the basis of this knowledge an inbound data packet containing a Session ID can be directed to the node processing corresponding communication session. The disadvantage in this method is that outbound data packets need to be inspected. Further, the knowledge (Session ID) needed for distributing data packets correctly can be obtained only during the handshake phase.
HTTP (HyperText Transfer Protocol) cookies are widely used in conjunction with web-based client-server connections. A server, when returning an HTTP object to a client in response to a client request, may also send a piece of state information which the client will store. Included in that state object is a description of the range of URLs (Uniform Resource Locators) for which that state is valid. Any future HTTP requests made by the client, which fall in that range will include a transmittal of the current value of the state object from the client back to the server. The state object is called an HTTP cookie. Connections belonging to the same communication session may be identified by means of an HTTP cookie in a similar manner to the SSL Session ID.
There is thus a problem in distributing inbound data packets belonging to a certain communication connection or session to the same node of a network element cluster, which processes outbound data packets belonging to said communication connection or session. Furthermore, there is a problem of how to flexibly share and balance load relating to the communication connections or sessions between the nodes of a network element cluster, the network elements being for example security gateways or servers.